Subject: Topology Tables in the APPN MIB

From: "R.E. (Robert) Moore (254-4436)" <[email-masked]>
Date: Thu, 14 Sep 95 12:34:52 EDT

I'd like to offer an alternative to Bob Clouston's appnNnNode<Tg>Cvs
proposal for reducing the size and simplifying future extension of the
APPN MIBs topology tables.  I'm going to argue that we can achieve a
signficant reduction in MIB size, and be well positioned for future
extensions, without introducing a whole class of problems that come with
composite objects of the type that Bob has proposed.

I use the term "composite object" to refer to an SNMP managed object that
contains what are inherently multiple pieces of information.  Ordinarily
SNMP MIBs do not contain composite objects--they have a separate object
for each piece of information they're representing.  This isn't to say
that composite objects are *never* justified, or never useful.  There
are, however, a number of difficulties that composite objects introduce,
so it's necessary to demonstrate that the benefits of using composite
objects in a particular case outweigh these difficulties.

Composite objects introduce the following difficulties:

1.  Unfriendly to MIB browsers and network management application
    builders--in fact, if very much information is packed into a
    composite object, retrieving its value with a MIB browser becomes
    essentially useless.

2.  Not granular enough for access control.  Admittedly security and
    access control are still spinning wildly in the SNMPv2 working group,
    but one point of agreement seems to be that the finest granularity
    for access control is at the level of an individual managed object.
    If we put all of the topology information for a node or TG into a
    single object, then we'd be closing the door forever to granting to a
    Management Station access to some, but not all, of the information.
    I just don't see that we're in a position t do this.

3.  IETF reaction.  Given that there's just a lot of information to
    represent in an APPN MIB, we've got a choice of how we want to
    "broaden the IETF's horizons":

      -  a big MIB, with a lot of objects
      -  a smaller MIB, with composite objects.

    My guess is that the IETF will be more comfortable with the first of
    these than with the second.

Rather than going to composite objects, I think we should trim down the
APPN.MIB.1 tables as follows:

0.  Our starting point is:

      - node non-FRSN table:  20 objects
      - TG non-FRSN table:    25 objects
      - node FRSN table:      20 objects
      - TG FRSN table:        25 objects
                             ____________
                      Total:  90 objects

1.  Remove the two non-FRSN tables, since they don't provide any value
    over and above that provided by the FRSN tables.

2.  Remove three objects that have no corresponding fields in the TDU
    itself:

      - appnNnNodeFREndptDepleted
      - appnNnNodeFRChainSupport
      - appnNnTgModemClass.

We're left with 18+24 = 42 objects, out of the original 90.  Bob
didn't give a number explicitly, but I think his proposal gives us
3+5 = 8 objects if we drop the non-FRSN tables, 14 if we keep them.

Assuming that we drop the non-FRSN tables, then, we see that 34
additional objects is the price we pay for avoiding the difficulties
that composite objects introduce.

So far as future migration is concerned, most of the activity at the
moment seems to be in the area of DLC signalling information.  For this
the MIB already has the appnNnTgDlcData object, which has overtones of
both a composite object and a C union.  If we increase the size of this
object, and generalize its description a bit, it should be able to handle
any DLC signalling extensions that might come along.

Bob

---

From: Bob Clouston <[email-masked]>
Date: Fri, 15 Sep 95 12:59:20 EDT

> composite objects of the type that Bob has proposed.
.. < stuff deleted>

>     composite object, retrieving its value with a MIB browser becomes
.. < stuff deleted>
.... < Bob Moore's proposal >

>     over and above that provided by the FRSN tables.
 ...
 
I need to read this in more detail, but doesn't removing the non-FRSN tables
make this even more unfriendly to MIB browsers, because the FRSN is not
well known, and in fact can change at any instance?  At one point I 
had suggested stripping down one of the tables to include just the node
name and FRSN; enough information to get to the other table.  Since the
FRSN can change, I had suggested stripping down the FRSN table, but I 
understand that this table has much more use to mgmt apps, so perhaps
the non-FRSN table could be stripped down instead?
Or perhaps accomodating a MIB browser isn't so important for these tables?
Something to think about.

Bob Clouston